|
|
|
|
|
Hi YK, We are confused this request, The failure is caused by app, We don't know how to fix it. If we test it with Android TV Standard launcher. we don't have these DPI failures. (I've confirmed it) After internal discussion, we don't plan to follow Intek, the reasons are as follows, 1. If we modify the HWC, who will be the owner of HWC in the future, we haven't modified HWC for our other customers before, we are not familiar with it. 2. All of Amlogic Android 12's customers are using REAL mode currently, I think Amlogic will fix many HWC related bugs in the future. If we use Fix mode, who can maintain these code. 3. The DPI issues are caused by app side in REAL mode. but you said that Intek still use REAL mode in Google certification, where is the difference? Did you mean that Intek use REAL mode but add another workaround for DPI issue? For DPI issues, as far as we know, Current HomeUI casued TvtsHdmiHostTestCases and CtsWindowManagerDeviceTestCases failures. For CtsWindowManagerDeviceTestCases case, we can add workaround for it, I think Digicap can also handle it. The HomeUI can detect that if CtsWindowManagerDeviceTestCases (packagename is "android.server.wm.displaysize") is installed or removed during testing CTS. If CtsWindowManagerDeviceTestCases is installed, HomeUI should set sys.skb.resolution.nonoverride as true. After CtsWindowManagerDeviceTestCases is completed, the CtsWindowManagerDeviceTestCases will be removed by CTS tool, at this time, the HomeUI can set sys.skb.resolution.nonoverride as false. I've verified this method. the result is good. For TvtsHdmiHostTestCases case, I've tried to add the same workaround (Check if TvtsHdmiHostTestCases is installed/removed, and set the corresponding property) but we still can see the DPI failures, (Based on my past experience, set property must be done before reconnecting hdmi to Integral2, check if TvtsHdmiHostTestCases is installed/removed is too late) According to this experience, maybe we should setprop as true when we plug out HDMI and set prop as false when user connect HDMI to normal TV. (if we connect to Integral2, the property will keep true) But currently, I don't know how to distinguish normal TV between Integral2. I'm not sure if this method can be implemented. I can't confirm any side effects at the moment, but I think this is a minimum modification. If Amlogic/Digicap have any idea, please let us know. Because I don't have source code of HomeUI, I don't know the behavior of HomeUI when HDMI Plug out/in. For TVTS case, I don't know why set property must be done before reconnecting HDMI to Integral2. I guess Digicap handle something when HDMI plug out/in. Thanks, Jason |
|
|
Hi Jason Let me explain the situation further. > 1. who will be the owner of HWC in the future AML will support additional issues. > 2. All of Amlogic Android 12's customers are using REAL mode currently, I think Amlogic will fix many HWC related bugs in the future. If we use Fix mode, who can maintain these code. AML can maintain these code > 3. The DPI issues are caused by app side in REAL mode. but you said that Intek still use REAL mode in Google certification, where is the difference? > Did you mean that Intek use REAL mode but add another workaround for DPI issue? I know right now is INTEK uses Realmode for Google approval, and I understand that DPI issues can be solved only by setting property. I don't know any additional information FYI * You need to use Realmode for Google approval. -> Google approval is not available in Fixed mode. (FXN requested a waiver for the Google test fail, but it was rejected.) * You must use Fixedmode to distribute to the field. -> Live-streams also need to be changed when using Realmode. https://jira.skbroadband.com/browse/BPM-19264 If Live-streams changes, all existing distributed STBs will be affected. Therefore, field distribution must use Fixedmode. So, Google approval and field distribution are the same FW, but they must work differently. The default should be set to Fixedmode(field distribution) * Currently, I made a request for HomeUI change, but it was basically rejected by SKB manager. In the case of complex requests, they will be rejected, but I will discuss the minimum modifications again. * In the case of DPI issues, it seems to be a bit of a timing issue. Is it possible to have additional debugging for that timing? If you know the exact details of the timing, we may be able to request additional requests to Digicap. I'll let you know when I know about HDMI Plugout/in in HomeUI.. And I think it would be better to proceed in a form similar to INTEK's method as possible. Thank you YK.Jung |
|
|
Hi YK, >>You need to use Realmode for Google approval. >>You must use Fixedmode to distribute to the field. Why Manufacturers should implement this request, we are not responsible for HWC. After Internal discussion, this request is very clear from SKB, It should be implemented by Amlogic, if there are any xTS side effect, It should also be fix by Amlogic. Amlogic should implement it for all manufacturers. and It will be convenient to maintain in the future. if each manufacturers implement their own dynamic switching function. it's hard to debug for Amlogic Currently, I'm investigating dynamically setting properties based on test modules. As you know, this side effect is made by Digicap, I think Digicap set resolution and density when booting to HomeUI and HDMI hotplug. I think Digicap can try to restore the original value when HomeUI detect TvtsHdmiHostTestCases module is installed. Thanks, Jason |
|
|
Hi Jason and Kerwin, I know your difficulties, but we are also in a very difficult situation. I think your opinion is right that this issue owner is Amlogic or Digicap. But Intek has their solution without help of Amlogic or Digicap, this is root cause you to support it. Skb dosen't like to invest something for solving it becasue money and time spend and we can't persuade them. And amlogic dosen't know to solve it even though they were working long time. So we have to do it. Please help us to solve it. |
|
|
Hi YK, >>But Intek has their solution without help of Amlogic or Digicap How can you confirm that if Intek's solution is correct or no side effect. >>amlogic dosen't know to solve it even though they were working long time The HWC is implemented by Amlgoic, if Amlogic doesn't know to solve it, Do you think we can fix it ? Let me check currently situation. 1. We are using REAL mode to pass certification. 2. But the REAL mode has resolution issue, so Amlogic provide workaround to Digicap, this workaround causes CTS/TVTS failures, Digicap provide the property to pass it => If Amlogic can implement mode switching function, I guess Digicap can remove workaround, there will no CTS/TVTS failures. 3. According to your comment, Live-streams must be played under Fix mode, the Live Channel is handled by SPTEK/Amlogic Based on item 2, 3, Why can't we ask Amlogic to implement it? Please try to convince Amlogic. Thanks, Jason |
|
|
Hi Jason, [ALT] But Intek has their solution without help of Amlogic or Digicap How can you confirm that if Intek's solution is correct or no side effect. [ALT] It is not important that there is side effect. Important thing is that Intek can pass in certification. [ALT] amlogic dosen't know to solve it even though they were working long time The HWC is implemented by Amlgoic, if Amlogic doesn't know to solve it, Do you think we can fix it ? [ALT] Ok, if you think so, do push Amlogic yourself. ALT won't care anymore Let me check currently situation. 1. We are using REAL mode to pass certification. 2. But the REAL mode has resolution issue, so Amlogic provide workaround to Digicap, this workaround causes CTS/TVTS failures, Digicap provide the property to pass it => If Amlogic can implement mode switching function, I guess Digicap can remove workaround, there will no CTS/TVTS failures. 3. According to your comment, Live-streams must be played under Fix mode, the Live Channel is handled by SPTEK/Amlogic Based on item 2, 3, Why can't we ask Amlogic to implement it? Please try to convince Amlogic. [ ALT ] ALT is doing best to find best solution. ALT had many meeting for it. But amlogic is saying that they has no solution for it. ALT doesn't know what to do anymore. If you can't agree with our opinion, you find to solution with amlogic. Google certification's owner is FXN. Thanks KANG |
|
|
Hi Wooshin, >>Google certification's owner is FXN. Yes, Foxconn is in charge of Google certification. but if we use standard launcher, we don't have this failures, the side effect is made by Digicap and Amlogic. Why can't the owner fix it? >>Important thing is that Intek can pass in certification. The important thing is not only certification, but also support for dynamic switching modes. If the request is just for certification, Foxconn can help try to figure out work aroud for it. But as far as I know. the new request also include that Live tv must be played in fix mode. Foxconn is not in charge of Live tv. Anyway, we know you already pushed Korean AML, we will try to push Taiwan AML. Thanks, Jason. |
|
|
Hi Jason, >>Google certification's owner is FXN. Yes, Foxconn is in charge of Google certification. but if we use standard launcher, we don't have this failures, the side effect is made by Digicap and Amlogic. Why can't the owner fix it? [ALT] I know already it but I can't control them( AML and Digicap ). Specially Digicap is very difficult to control. Do discuss with them yourself. >>Important thing is that Intek can pass in certification. The important thing is not only certification, but also support for dynamic switching modes. If the request is just for certification, Foxconn can help try to figure out work aroud for it. But as far as I know. the new request also include that Live tv must be played in fix mode. Foxconn is not in charge of Live tv. [ALT] I don't know why you are saying "LIVE TV" repeatedly, Intek didn't change live tv module, they add some code for dynamic switch mode to pass google certification. Anyway I will wait you to find out good solution. Thanks KANG, |
|
|
Hi Wooshin, >>[ALT] I don't know why you are saying "LIVE TV" repeatedly, Intek didn't change live tv module, they add some code for dynamic switch mode to pass google certification. >>Anyway I will wait you to find out good solution. Because your additional request is that LiveTV and distributed FW should be run under Fix mode. The original issue is very simple, try to find out the solution to pass certification under the real mode. If all function run under the real mode. We don't need to consider Fix mode and dynamic switch function, we just try to help Digicap find out the workaround without setting property manually under Real mode. Thanks, Jason |
|
|
Hi Jason, Please remind below. >>You must use Fixedmode to distribute to the field. Thanks. |
|
|
Hi Jason, SKB JIRA ticket is https://jira.skbroadband.com/browse/FSTB12-118. SKB want to know about current status. Please add comment on skb jira ticket. Thanks. |
|
|
Hi Wooshin, Currently no update. We will discuss it with Taiwan AML. As you already know, this bug is not causes by manufacturer. We don't know how to improve it. According to YK's comment, AML will support additional issues and maintain HWC after manufacturer modified. If Amlogic doesn't know how to improve it. How can they maintain HWC . so we need to discuss it with AML first. Thanks, Jason |
|
|
Hi Jason >> 1. Last year, All vendors used Fix mode to develope (because fix mode support 1080i) >> => All Manufacturers have TVTS issues and Cts-verifier issue, and Google can not waive it >> 2. Change to Real mode due to Google certificatoin issue >> => All Manufacturers have to update BTF to support setting 1080i resolution The above are correct * History in which non-override property was created after switching to Real mode - Real mode features a dynamic change in frame buffer size from 720p resolution to 1280 x 720 But The HomeUI(Digicap) was implemented in a fixed mode (Framebuffer size was fixed at 1920 x 1080 in all resolutions) So Real mode 720p resolution has a large screen problem. There were two solutions to this 1) Digicap redesigned the HomeUI using the DPI method 2) Use override for frame buffer size on 720p SKB/Digicap rejected 1) Therefore, Digicap used the override method 2) but 720p framebuffer size override method causes xTS Fail Therefore, create a non-override property and add a property to pass through xTS (setprop sys.skb.resolution.nonoverride true) * Additional information from AML FAE about INTEK STB - The content that INTEK's field distribution is fixed mode is wrong. According to the INTEK code, INTEK's STB mode is Real-mode In other words, INTEK set FW to Real-mode to pass through xTS and implemented the advantages of Fixed mode additionally, so there was no 720p issue. * SKB's request is - It is about making it no problem when field distribution(BMT) and Google approval(3PL). Anyway, INTEK has found a solution, so each manufacturer should implement it on its own. Thanks YK.Jung |
|
|
Hi YK, * Additional information from AML FAE about INTEK STB - The content that INTEK's field distribution is fixed mode is wrong. >> According to the INTEK code, INTEK's STB mode is Real-mode Could you check it again? According to the attachment you provided, the INTEK's code is Fix mode. And they use /sys/class/itk_debug/skbmode to get current mode. it looks like they implement switching function. is the information wrong now? >>In other words, INTEK set FW to Real-mode to pass through xTS and implemented the advantages of Fixed mode additionally, so there was no 720p issue. Could you please confirm your request again? We discussed it with Taiwan AML yesterday. He also said he received the "switching function" request from Korea. Thanks, Jason |
|
|
Hi Jason, * Additional information from AML FAE about INTEK STB - The content that INTEK's field distribution is fixed mode is wrong. >> According to the INTEK code, INTEK's STB mode is Real-mode Could you check it again? According to the attachment you provided, the INTEK's code is Fix mode. And they use /sys/class/itk_debug/skbmode to get current mode. it looks like they implement switching function. is the information wrong now? ===> Intel is using fixed mode in normal status, but it will be changed real mode in google test mode. Thanks. |
|
|
Hi Wooshin, YK, I discussed this topic with YK in recent days. Let me summarize current situation, if my thinking is wrong, please correct me. 1. SKB doesn't care about Fix/Real mode switching function. SKB only care that we should have no Google certification/BMT issue. After internal discussion, Regardless of whether the Fix/Real mode switching function is implemented or not, we all need help from Digicap. 1-1. If we don't implemented Fix/Real mode switching function. we should address current Google certification issue. (Pass TVTS without setting sys.skb.resolution.nonoverride manually) According to the history of HomeUI. HomeUI was implemented under Fix mode. After all manufacturers changed to Real mode, HomeUI has large screen issue Digicap implemented override-related function. and provide to us non-override property "sys.skb.resolution.nonoverride" to avoiding running their function. According to my past experience, this property "sys.skb.resolution.nonoverride" must be set before HDMI Plug in/out event. We don't have the source code of HomeUI, but I think we need to trigger HDMI event to let some function available. If we want to pass xTS without settings "sys.skb.resolution.nonoverride" manually, I think Digicap can use "persist.sys.skb.mode". the "persist.sys.skb.mode" is accepted by our 3PL. because it's related to network. 3PL used it to skip SKB network checking. The test flow will become as follows, a). set persist.sys.skb.mode as 1 (for using Taiwan network) b). reboot devices to make it available These 2 steps are accepted for 3PL. Because the property sys.skb.resolution.nonoverride is not persist. the value of this property will not be kept after reboot. c). During device startup, HomeUI will check the property persist.sys.skb.mode c-1, if value is 1, Do not run override function c-2, if value is 0, Run the override function For xTS auto Testing, we guided 3PL to stay at SKB login page for testing. so Digicap just need to confirm when persist.sys.skb.mode is 1. the login page will not be enlarged. if 3PL want to test SmokeTest, they need to login SKB account, at that time, they need Korean network. so the persist.sys.skb.mode is 0. the UI will run override function. I think this is the simplest way to pass TVTS. But we need to Digicap's help. 1-2. If we implemented Fix/Real mode switching function. we still need Digicap's help. In current situation (current is real mode), we need to set sys.skb.resolution.nonoverride manually and plug out HDMI then insert to Integral2 then testing TVTS. (This means that we need to set the property manually and trigger HDMI plug event to make override function disable) so even if we implemented Fix/Real mode switching function, when we change mode to Real mode for Google certification. We still need to set this property manually. if we implemented Fix/Real mode switching function, we still need Digicap to remove the override related code. because Digicap doesn't need this code. the HomeUI will be run under Fix mode, they don't have enlarged issue. After changing mode to Real mode for certification, the override's related code has been removed, so we don't have TVTS issue. Based on 1-1 and 1-2. We all need help from Digicap. Please discuss with Digicap first and and let us know their opinion. for 1-1, 1-2, we need Digicap to provide test apk for verification. Thanks, Jason |
|
|
Hi Jason, About 1-1, Do you have method to set property "sys.skb.resolution.nonoverride" yourself according to follow "persist.sys.skb.mode" ? Thanks |
|
|
Hi Wooshin, >>About 1-1, Do you have method to set property "sys.skb.resolution.nonoverride" yourself according to follow "persist.sys.skb.mode" ? "set property persist.sys.skb.mode as 1 manually, the system will set sys.skb.resolution.override true automatically" is doable. I have verified the flow below. 1. Set persist.sys.skb.mode as 1 manually, system will set sys.skb.resolution.override as true automatically. 2. Reboot the device, the value persist.sys.skb.mode is persist, so value 1 is kept, but the value of sys.skb.resolution.override will gone 3. During startup, System check the persist.sys.skb.mode is 1, set sys.skb.resolution.override as true automatically. 4. When HomeUI see the sys.skb.resolution.override is true, HomeUI doesn't run the override-related function. The key is that Step 3 must be executed before Step 4. I've verify this flow, the TVTS result is good. But this approach is a bit redundant. If Digicap can use property "persist.sys.skb.mode" directly, they can check if HomeUI should run the override-related function during system startup. Regarding to this approach, the sys.skb.resolution.override binds with persist.sys.skb.mode. so if we want to use this approach, we need to check if override-related is not executed, there is no side effect in xTS auto test. Thanks, Jason |
|
|
Hi Jason, I have a question about upper case. You got a good result for TVTS but I wonder is there any test in smoke to set resolution 720P ? If you know any test (set 720P), check please it too. And digicap is calling override function after finishing android boot animation and at time call resolution change function. |
|
|
Hi Wooshin, I've discussed this question with YK, When Testing SmokeTest, 3PL must to login SKB account to HomePage, so 3PL need to use Korean VPN, the value of persist.sys.skb.mode will be set as 0 for Korean network, and non override will be false. if the non-override is false, I think the behavior will be the same as before. Thanks, Jason |
|
|
Hi Wooshin, YK, Test image 15.537.100 /release_by_fxn/tmp/mantis1765/ Verify: setprop persist.sys.skb.mode 1 then getprop sys.skb.resolution.override to confirm if the value is true reboot device getprop sys.skb.resolution.override to confirm if the value is true again. Thanks, Jason |
|
|
Hi Jason, I have tested your test FW, it works the property is changed correctly as you said. Verify: setprop persist.sys.skb.mode 1 then getprop sys.skb.resolution.nonoverride to confirm if the value is true reboot device getprop sys.skb.resolution.nonoverride to confirm if the value is true again. But I tried to change resolution by SKB menu, it does not work. Could you please check it? Thank you. Kim |
|
|
Hi JunGyu, When you change the resolution, What are the follow values? persist.sys.skb.mode sys.skb.resolution.nonoverride Thanks, Jason |
|
|
Hi JunGyu, Sorry, I forget to build ResolutionService apk I'll include it. Thanks, Jason |
|
|
Hi JunGyu, I've rebuilt the image containing the ResolutionService apk Test image 15.537.200 /release_by_fxn/tmp/mantis1765/ Thanks, Jason |
|
|
Hi Jason, I tested it after setting the resolution to 720p by 15.537.200 FW. 1. When first boot with the persist.sys.skb.mode property not set Normal operation at 720p resolution. There doesn't seem to be any particular issue to be concerned about. 2. When changing to persist.sys.skb.mode 1 and reboot device, A known issue, UI growing issue occurred. 3. When rebooting after setting persist.sys.skb.mode to 0 Live screen shrinking issue and UI screen abnormal symptoms occurred. After reboot again, this issue is cleared. property is applied normally as below. [persist.sys.skb.mode]: [0] [sys.skb.resolution.nonoverride]: [false] [vendor.sys.resolution]: [720p60hz] I think it could be a problem for the third issue. Thank you. Kim |
|
|
Hi JunGyu, I have one question, I don't know why you need to set persist.sys.skb.mode 1 in HomeUI. For field user. The persist.sys.skb.mode is always 0. they use Korean SKB network, SKB webview. For Google Certification auto Test and Cts-verifier We've guided 3PL test at login screen. They set persist.sys.skb.mode as 1 for using Taiwan network and Google Webview. When persist.sys.skb.mode is 1, the sys.skb.resolution.nonoverride will be set as true, It will cause HomeUI enlarge issue. But we stayed at login screen. so I don't think 3PL will see it. I think Digicap only need to confirm the login page will not be enlarged when sys.skb.resolution.nonoverride is true. For Google Certification - SmokeTest 3PL must to login SKB account to check function of HomeUI, Before login SKB account, they need to use Korean network and SKB webview For using SKB DNS (Korean network), the value of persist.sys.skb.mode is 0, the sys.skb.resolution.nonoverride will be false. I don't think there will be a HomeUI enlarged problem. Is there any situation in HomeUI that we need to set persist.sys.skb.mode as 1? Thanks, Jason |
|
|
Hi Jason, I don't think the screen size issue is a problem either. The issue I'm concerned about is the third issue. (Live screen shrinking issue and UI screen abnormal symptoms occurred) If 3PL proceed with Google authentication, it is expected that persist.sys.skb.mode will be changed from 1 to 0 to test SmokeTest. If auto test and smoke test STB are separated, seems to be no problem. Thank you. Kim |
|
|
Hi JunGyu, I think the behavior of Step#3 should be the same as Step#1. In the Step#1, The values persist.sys.skb.mode and sys.skb.resolution.nonoverride are both empty (null value). In the Step#3, sys.skb.resolution.nonoverride is false. If the behavior is different between "false" and "empty", I think you can check it with Digicap first. By the way, I followed your step, and tried to reproduce it with "user-build", I haven't seen the issue in Step#2, Which monitor did you use, I've verified 4K TV and 1080p Monitor, I haven't seen the issue in Step#2. Did you ever change the resolution during the reproduce step? Thanks, Jason |
|
|
Hi Jason, Thank you for your comment. Step#3 issue is checking with Amlogic by below jira ticket. https://jira.skbroadband.com/browse/FSTB12-120 By the way, I also tested with "user-build" FW, I still encounter the enlarge issue. I have tested with 1080p monitor and I only change the resolution in Step#1. Thank you. Kim |
|
|
Hi JunGyu, I didn't set resolution in Step#1, and when I do the step#2, I don't see the enlarged issue. As we discussed on wechat, I think this enlarge issue will not occur on field. because user can set the resolution. but user will not set the persist.skb.mode. we don't need to consider this case. Thanks, Jason |
|
|
Hi Jason, https://jira.skbroadband.com/browse/FSTB12-120 issue looks not relative with this issue. I will discuss with AML how to fix it and "override" property changing algorithm according to "skb.mode" is good solution to pass google certification and BMT. Next Monday , I will inform YK and YK will update if could be commit it. Thanks. |
|
|
Hi Jason I made a proposal to SKB with the "skb.resolution.nonoverride" setting method according to "persist.sys.skb.mode" proposed by FXN. However, SKB is telling us not to use "skb.resolution.nonoverride" itself. That is ,SKB is telling us to follow INTEK's approach. Currently, INNOPIA has also proceeded with INTEK's approach, and the basic task has been completed. That is , it is said that the Google test items that failed in the existing fixed mode has been passed. and additional verification is in progress at INNOPIA. Here's what I heard from INNOPIA during the meeting. - INTEK code analysis completed at INNOPIA > Operates in fixed mode (fixed mode for BMT/field distribution) mSkbMode is said to be true when Google tests That is, the failed items that occurred during the Google test with the fixed mode become pass due to the mSkbMode true. - Additional functions implemented for the RealMode are not used (since it is in fixed mode) https://mantis.cnsbg.foxconn.com/vaas/view.php?id=1711 * And we should also check whether the above(INNOPIA's word) is true. Anyway, it seems that we should also follow INTEK's approach. In addition, I tried to understand based on what I heard in INNOPIA or AML, but there is a limit to understanding So we also will analyze the code currently provided by INTEK. Anyway, the current conclusion is that we should also follow the method provided by INTEK. Thank you YK.Jung |
|
|
Hi YK, For CTS result of binding property method. We tested all test suites except smoke test. (because the skb.mode of SmokeTest is 0, it's the same as before, we don't need to verify it) the results are pass. For the switching mode that you request today, We found a simple way to implement switching mode. but my question is still as follows, After we switch to the Real mode, We still encounter override issue in TVTS. Could Digicap remove the override function, I think they can remove it Because all manufacturers will use fix mode for normal operation, the field user won't encounter screen enlarge issue. I've tried Intek's code before, but we didn't have their full modification. so After I modified it. I saw the broken screen in CTS-Verifier. so I found a simple way to implement switch mode function, but I need Digicap's help. According to your comment, - Additional functions implemented for the RealMode are not used (since it is in fixed mode) https://mantis.cnsbg.foxconn.com/vaas/view.php?id=1711 Could Digicap remove the Additional function and give us test apk Thanks, Jason |
|
|
Hi Jason As far as I know, if you set "skb.resolution.nonoverride: to true, the override function does not work. ( It is now the same effect as removed.) Therefore, if you want to test it, fix "skb.resolution.nonoverride" to true in the initial booting script. And I'm not sure , when I check INTEK's box, "skb.resolution.nonoverride" always seems to be true. >>I've tried Intek's code before, but we didn't have their full modification If you want to know about the use of a specific variable or functions in the INTEK code, I can check it additionally and forward it to you >>According to your comment, >>- Additional functions implemented for the RealMode are not used (since it is in fixed mode) >> https://mantis.cnsbg.foxconn.com/vaas/view.php?id=1711 >>Could Digicap remove the Additional function and give us test apk The additional function I mentioned is what FXN implemented. support 1080i in RealMode at BTF_HAL (FXN call "setUserPreferredDisplayMode()" by using HIDL) Please let me know if there is anything necessary to implement SKB's request Thank you YK.Jung |
|
|
Hi YK, The following modification is the simple implementation for mode switching. 1. device/amlogic/franklin -HWC_ENABLE_REAL_MODE : false 2. hardware/amlogic/ --- a/hwcomposer/common/hwc/HwcConfig.cpp +++ b/hwcomposer/common/hwc/HwcConfig.cpp @@ -111,6 +111,7 @@ hwc_pipe_policy_t HwcConfig::getPipeline() { hwc_modes_policy_t HwcConfig::getModePolicy(int disp) { UNUSED(disp); +#if 0 #ifdef HWC_ENABLE_FULL_ACTIVE_MODE return FULL_ACTIVE_POLICY; #elif defined HWC_ENABLE_ACTIVE_MODE @@ -120,7 +121,21 @@ hwc_modes_policy_t HwcConfig::getModePolicy(int disp) { #else return FIXED_SIZE_POLICY; #endif +#else + char const *prop_name = "persist.vendor.skb.mode"; + char buf[PROPERTY_VALUE_MAX]; + if (property_get(prop_name, buf, NULL) > 0) { + MESON_LOGE("getSkbMode in hwcomposer is %s\n", prop_name); + if ((strcmp(buf, "true") == 0) || (strcmp(buf, "1") == 0)) { + return REAL_MODE_POLICY; + } else { + return FIXED_SIZE_POLICY; + } + } else { + return FIXED_SIZE_POLICY; + } } +#endif 3. system/core/ set "skb.resolution.nonoverride: to true in rootdir/init.rc I think this method is more clear than Intek's, Intek's method is moving the each Real mode function to FixedSizeModeMgr.cpp and use mSkbMode flag to run different code. Our method is simpler, when HW composer is created, HW composer will create a corresponding object based on persist.sys.skb.mode. The default value of persist.sys.skb.mode is 0. so the default mode is fix mode. we set the persist.sys.skb.mode as 1. then reboot device, the mode will change to real mode. How to verify: please refer to https://mantis.cnsbg.foxconn.com/vaas/view.php?id=1582 1. Install CTS-Verfier and test "Mode Switching Test ", if the persist.sys.skb.mode is 0, (the mode is fix mode), you can NOT see "START TEST" button. 2. setprop persist.sys.skb.mode 1, and reboot device -> Change mode to real mode. 3. Open CTS-Verfier and test "Mode Switching Test ", you can see the "START TEST" button. 4. you can set persist.sys.skb.mode as 0 and reboot device, the mode will change back to fix mode. I use this method to verify mode switching function. It looks good to me. We also verify TVTS TvtsHdmiHostTest, the result is good. I think Amlogic also can accept our solution, because it easier for maintenance. Because we only change getModePolicy function. Please let me know your Opinion, if you need test image, I can provide test image to you. But for mode switching implementation, the default mode will change to Fix, I think we should review the following patch frameworks/base 6045a773c539 bootanimation: lower than 1080p,the bootanimation is too large[1/1] <--- I don't know why Intek revert it, is it related to REAL_MODE ? 7e9268192895 bootanimation: fix resize window error on android S <--- The author of this patch is Google, I don't know why Intek revert it vendor/amlogic/common 1ca4150 dpi: wm reset in DisplayDensityManager[1/1] <--- I don't know why Intek revert it, is it related to REAL_MODE ? frameworks/base ffe12968763e display: sync wm settings when dc initial [1/1] <--- I don't know why Intek revert it, is it related to REAL_MODE ? According to https://mantis.cnsbg.foxconn.com/vaas/view.php?id=1582 Amlogic privde AMANDROIDS-97 patch for REAL_MODE 1080i, but we will use fix mode for distribute FW, should we revert it too? Thanks, Jason |
|
|
Hi Jason .. >>+ return REAL_MODE_POLICY; >>+ } else { >>+ return FIXED_SIZE_POLICY; .. >>The default value of persist.sys.skb.mode is 0. >>so the default mode is fix mode. >> Please let me know your Opinion, if you need test image, I can provide test image to you. I think it is right to use it in fixed mode as default and your current approach seems fine. but I need to check it too, so please send me a Test FW ( ND / SD version) About the patches that INTEK reverted to I will let you know after checking with AML again. Thank you YK.Jung |
|
|
Hi YK, Test image 15.537.300 /release_by_fxn/tmp/mantis1765/switch_mode Change log: 1. set default mode as fix mode 2. Implement switch mode in HWC 3. set sys.skb.resolution.nonoverride true in init.rc 4. Remove ResolutionHelper.apk 5. Revert the following patch like Intek project: frameworks/base 2023-08-08 18:05:07 +0800 | jason.tf.ling@fii-.. | 05acb10cf001 | Revert "bootanimation: lower than 1080p,the bootanimation is too large[1/1]" 2023-08-08 18:03:01 +0800 | jason.tf.ling@fii-.. | b5692d62ee34 | Revert "display: sync wm settings when dc initial [1/1]" 2023-08-08 18:02:23 +0800 | jason.tf.ling@fii-.. | 5e32ffb8da34 | Revert "bootanimation: fix resize window error on android S" project: vendor/amlogic/common 2023-08-08 18:05:30 +0800 | jason.tf.ling@fii-.. | 1de6b2f | Revert "dpi: wm reset in DisplayDensityManager[1/1]" Thanks, Jason |
|
|
Hi YK, I attach CtsVerifier.apk, you can verify switch mode, too. Thanks, Jason |
|
|
Hi JunGyu, After discussion on WeChat I re-upload the test image Test image 15.537.400 /release_by_fxn/tmp/mantis1765/switch_mode Change log: 1. set default mode as fix mode 2. Implement switch mode in HWC 3. set sys.skb.resolution.nonoverride true in init.rc 4. Remove ResolutionHelper.apk 5. restore BTF API for fix mode << update this part 6. Revert the following patch like Intek project: frameworks/base 2023-08-08 18:05:07 +0800 | jason.tf.ling@fii-.. | 05acb10cf001 | Revert "bootanimation: lower than 1080p,the bootanimation is too large[1/1]" 2023-08-08 18:03:01 +0800 | jason.tf.ling@fii-.. | b5692d62ee34 | Revert "display: sync wm settings when dc initial [1/1]" 2023-08-08 18:02:23 +0800 | jason.tf.ling@fii-.. | 5e32ffb8da34 | Revert "bootanimation: fix resize window error on android S" project: vendor/amlogic/common 2023-08-08 18:05:30 +0800 | jason.tf.ling@fii-.. | 1de6b2f | Revert "dpi: wm reset in DisplayDensityManager[1/1]" Thanks, Jason |
|
|
Hi Jason >> frameworks/base >> 6045a773c539 bootanimation: lower than 1080p,the bootanimation is too large[1/1] <--- I don't know why Intek revert it, is it related to REAL_MODE ? >> 7e9268192895 bootanimation: fix resize window error on android S <--- The author of this patch is Google, I don't know why Intek revert it >> vendor/amlogic/common >> 1ca4150 dpi: wm reset in DisplayDensityManager[1/1] <--- I don't know why Intek revert it, is it related to REAL_MODE ? >> frameworks/base >> ffe12968763e display: sync wm settings when dc initial [1/1] <--- I don't know why Intek revert it, is it related to REAL_MODE ? These four patchs are a fix for errors that occur only at 720p resolution in Realmode. That is , Just like INTEK, we have to revert. Thanks YK.Jung |
|
|
Hi YK, How about AMANDROIDS-97 ? These patches support 1080i in REAL_MODE. If default mode is Fix mode, Should we keep it? By the way, Could you check the following patch? packages/apps/TvSettings/ Author: tim.cho <tim.cho@amlogic.com> AuthorDate: Mon Jun 12 20:53:11 2023 +0900 Commit: tim.cho <tim.cho@amlogic.com> CommitDate: Tue Jun 13 09:19:38 2023 +0900 TvSetting: Fix 720P 1/4 boot UI black issue [1/1] This patch related to sys.skb.resolution.nonoverride, should we need it ? Thanks, Jason |
|
|
Hi Jason >> How about AMANDROIDS-97 ? >> These patches support 1080i in REAL_MODE. If default mode is Fix mode, Should we keep it? I'm not sure about this right now. Currently, RealMode is used for Google auto testing, but I don't know if it affects Google testing. >> packages/apps/TvSettings/ >> Author: tim.cho <tim.cho@amlogic.com> >> AuthorDate: Mon Jun 12 20:53:11 2023 +0900 >> Commit: tim.cho <tim.cho@amlogic.com> >> CommitDate: Tue Jun 13 09:19:38 2023 +0900 >> TvSetting: Fix 720P 1/4 boot UI black issue [1/1] >> This patch related to sys.skb.resolution.nonoverride, should we need it ? AML say that INTEK revert the patch we don't need it either. Thank you YK.Jung |
|
|
Hi YK, For switching mode function, We plan to verify Full xts (including SmokeTest, because SmokeTest will use Fix mode) 1. Please let me know the Jira id for switch mode implementation. I want to add local commit first 2. Should we also need to verify Mandatory456 Peter hasn't pushed these patches to bitbucket. What is your opinion? Thanks, Jason |
|
|
Hi Jason >> 1. Please let me know the Jira id for switch mode implementation. >> I want to add local commit first I just made it and I'll add the related content. Please use the JIRA below. https://jira.skbroadband.com/browse/BPM-21458 >> 2. Should we also need to verify Mandatory456 >> Peter hasn't pushed these patches to bitbucket we need to check the operation of it for about a week. ( AML will also be verified ) After the verification is complete, the these patchs will be officially distributed by Amlogic. After it is officially distributed, you can push it to the bitbutcket. So please don't push until then Thanks YK.Jung |
|
|
Hi YK, Our QA are working SWAN 19.540.22, When they finish the 15.540.22 and you have verified the Mandatory456, we can start verifying (switching mode + Mandatory456) by xTS tool next week. Thanks, Jason |
|
|
Hi Jason There is a meeting about ATV12 at 2 pm tomorrow(8/17). Please update the progress by noon tomorrow. Thanks YK.Jung |
|
|
Hi YK, Our QA just finished Swan test yesterday, they started eagle12 test this morning. And Google released new tool last week, so we are using new tool to verify the image (including switch mode implementation and mandatory456) if you need test image, please let us know. Status: (8/16) CTS: In progress CTS-V: not started CTS-ON-GSI: In progress GTS: In progress TVTS: In progress VTS: Done STS: Done SmokeTest: In progress Thanks, Jason |
|
|
Hi Jason, Please share the FW(SD) as you said.(including switch mode implementation and mandatory456) We will do aging test in several scenario. Thank you, Kim |
|
|
Hi JunGyu, Test image 15.537.500 /release_by_fxn/tmp/mantis1765/switch_mandatory456 Change log: 1. Apply Mandatory456 2. set default mode as fix mode 3. Implement switch mode in HWC 4. set sys.skb.resolution.nonoverride true in init.rc 5. Remove ResolutionHelper.apk + restore BTF API for fix mode 6. Revert TvSetting: Fix 720P 1/4 boot UI black issue [1/1] 7. Revert the following patch like Intek project: frameworks/base 2023-08-08 18:05:07 +0800 | jason.tf.ling@fii-.. | 05acb10cf001 | Revert "bootanimation: lower than 1080p,the bootanimation is too large[1/1]" 2023-08-08 18:03:01 +0800 | jason.tf.ling@fii-.. | b5692d62ee34 | Revert "display: sync wm settings when dc initial [1/1]" 2023-08-08 18:02:23 +0800 | jason.tf.ling@fii-.. | 5e32ffb8da34 | Revert "bootanimation: fix resize window error on android S" project: vendor/amlogic/common 2023-08-08 18:05:30 +0800 | jason.tf.ling@fii-.. | 1de6b2f | Revert "dpi: wm reset in DisplayDensityManager[1/1]" Thanks, Jason |
|
|
Hi YK, Version 15.537.500 Update Status: (8/17) CTS: Retrying CTS-V: not started CTS-ON-GSI: Retrying GTS: Done TVTS: Almost Finished VTS: Done STS: Done SmokeTest: Almost Finished (will be finished within today) Thanks, Jason |
|
|
Hi YK, Version 15.537.500 Update Status: (8/18) CTS: Done CTS-V: Done CTS-ON-GSI: Done GTS: Done TVTS: Done VTS: Done STS: Done SmokeTest: Done According to our plan, we will rebuild 15.537.502 to pretest. You can get the image/ota in following folder /release_by_fxn/smart3/ATV12/k000c-537r502_SU-20230818-BFX-AT100 /release_by_fxn/smart3/ATV12/k000c-537r502_SD-20230818-BFX-AT100 Thanks, Jason |
|
|
Hi Jason Thank you for the update YK.Jung |
|
|
Hi Jason I have a meeting with SKB today. Please update the progress of the v15.537.502 pre-test by 1:00PM (KT) Thank you YK.Jung |
|
|
Hi YK, Version: 15.37.502 Update Status: (8/24) CTS: Done CTS-V: Done CTS-ON-GSI: Done GTS: Done TVTS: Almost finished VTS: Done STS: Done SmokeTest: Almost finished I'll collect/review the reports today, and forward it to 3PL tomorrow. Thanks, Jason |
|
|
Hi YK, The mode switching function has been implemented. Thanks, Jason |
|
|
Hi Jason During OS12, a new Manufacturer joined SKB, and several Google-related issues have been reported at new Manufacturer One of them is the issue of sys.skb.resolution.nonoverride. In the case of this flag, it is used temporarily, so SKB wants to remove the code/flag at HomeUI The Home UI for testing with sys.skb.resolution.nonoverride flag / override code deleted has been released. https://jira.skbroadband.com/browse/AMANDROIDS-97 SKB_STB_Home_UI5.0_SMART3VCS_v1.24.0_vc1315_r27321_foxconn_20240221.apk INTEK / INNOPIA are also under consideration with the removed HomeUI. sys.skb.resolution.nonoverride is always used as true at Smart3 OS12 FXN In my opinion, it is expected that there will be no problem, but it needs to be verified. So please use this HomeUI to make sure there are no problems with Google testing regarding override Thank you YK.Jung |
|
|
Hi Jason After applying the home UI below, please check if there are no issues in the Google test. SKB_STB_Home_UI5.0_SMART3VCS_v1.24.0_vc1315_r27321_foxconn_20240221.apk INTEK said there is no problem with the Google test result. Please check it Thank you YK.Jung |
|
|
Hi Jason Please update the test results INNOPIA said also there is no problem. Thank you YK.Jung |
|
|
Hi YK, I've verify SKB_STB_Home_UI5.0_SMART3VCS_v1.24.0_vc1315_r27321_foxconn_20240221.apk with the latest UI542 code (3/19) with the following cases >For DPI issues, as far as we know, Current HomeUI casued TvtsHdmiHostTestCases and CtsWindowManagerDeviceTestCases failures. Both passed. But during testing, we saw the following black screen with bell + wifi icon 15.537.8 => During the testing, the screen sometimes will be enlarged 15.542.x + new HomeUI => During the testing, the screen will be black with bell + wifi icon Thanks, Jason |
|
|
bell.png (12,678 bytes) |
|
|
Hi Jason I will close this issue because the results of the Smart3 Google test(v15.542.130/v15.542.64/v15.542.60) have passed. Thank you for your support YK.Jung |
- yk.jung ( (ALTech) Younkwang Jung ) developer
